自己從0開始建資料庫的機會不多，所以突然又重新思考了一下有沒有必要拆成5個表格，之後也去問了Claude AI。

跟他說明了我的資料層級跟主鍵、外鍵設計，而在使用上使用者、平面圖跟房間通常更動次數較低，家具跟收納物會頻繁的更動。

層級與關係：使用者>平面圖>房間>家具>收納物

Claude AI是給我正向的回饋，代表我一開始的想法沒錯，靈活又高效就是我心中理想的DB設計٩(๑•̀ω•́๑)۶

• 清晰的數據結構：每個實體都有其獨立的集合，使得數據模型非常清晰。
• 高度的靈活性：可以獨立地管理和更新每個實體。
• 精細的訪問控制：如果需要，可以對不同的集合設置不同的訪問權限。
• 高效的更新：當只需要更新特定類型的實體時，不會影響其他相關實體。
• 查詢效率：通過使用主鍵和外鍵，你可以有效地關聯數據，而不需要多次查詢。

考慮到你提到的使用模式（平面圖和房間不常更動，家具和物品經常變動），這種分離的結構實際上是很合適的：

• 它允許你獨立地、高效地更新經常變動的家具和物品，而不會影響較穩定的平面圖和房間數據。
• 通過使用主鍵和外鍵，你可以在需要時輕鬆地關聯這些實體，而不會犧牲查詢效率。

所以我繼續完成 API 開發，目前是先把模型建起來，還有所有的getList寫好，getList的部份昨天截過圖了，今天展示模型就好，也因為最近剛上完資安的課，對於欄位跟IP、Port號外露特別敏感，所以只能打碼給大家看了。

Model.ts

import mongoose, { Document, Schema } from 'mongoose';

// 定義 FloorPlan 的接口
interface IFloorPlan extends Document {
  ****Id: string;
  ****Name: string;
  ....
}

// 定義 FloorPlan 的 schema
const floorPlanSchema: Schema<IFloorPlan> = new Schema({
  ****Id: {
    type: ****,
    required: true,
  },
  ****Name: {
    type: ****,
    required: true,
  },
  ....
});

// 定義 FloorPlan 模型，並指定集合名稱為 '****'
const FloorPlan = mongoose.model<IFloorPlan>('FloorPlan', floorPlanSchema, '****');

export default FloorPlan;